apps/deploy-web/src/services/session/session.service.spec.ts (1)

144-170: Make duplicate-user test resilient to backend status mapping.

Line [145] hardcodes 409, but this flow is contract-sensitive. Consider covering both 409 and 422 to prevent brittle behavior across backend versions.

Suggested test hardening

-    it("returns user_exists when user already exists and sign-in fails", async () => {
-      const { service, consoleApiHttpClient, externalHttpClient } = setup();
-
-      consoleApiHttpClient.post.mockResolvedValueOnce({
-        status: 409,
+    it.each([409, 422])("returns user_exists when user already exists (status %s) and sign-in fails", async duplicateStatus => {
+      const { service, consoleApiHttpClient, externalHttpClient } = setup();
+
+      consoleApiHttpClient.post.mockResolvedValueOnce({
+        status: duplicateStatus,
         data: {
           message: "The user already exists."
         },
         headers: {}
       });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/deploy-web/src/services/session/session.service.spec.ts` around lines
144 - 170, The duplicate-user test is brittle because it hardcodes
consoleApiHttpClient.post to return status 409; update the test around
service.signUp to accept the backend mapping change by mocking
consoleApiHttpClient.post to return either 409 or 422 (e.g., parametrize or set
up two sub-cases) while keeping externalHttpClient.post mocked as shown; ensure
the assertion on the resulting error (message "Such user already exists but
credentials are invalid" and code "user_exists") and the call count assertions
for consoleApiHttpClient.post and externalHttpClient.post remain unchanged so
the behavior is validated for both backend status variants.

apps/deploy-web/src/components/onboarding/VerifyEmailPage/VerifyEmailPage.spec.tsx (1)

10-13: Prefer getByText for this presence check.

queryByText(...).toBeInTheDocument() makes failures harder to debug because you lose the thrown query error and DOM snapshot.

Based on learnings: In apps/{deploy-web,provider-console}/**/*.spec.tsx files: Use getBy methods instead of queryBy methods when testing element presence with toBeInTheDocument() because getBy throws an error and shows DOM state when element is not found, providing better debugging information than queryBy which returns null.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/deploy-web/src/components/onboarding/VerifyEmailPage/VerifyEmailPage.spec.tsx`
around lines 10 - 13, Change the presence assertion in the "shows redirect
loading text" test to use screen.getByText instead of screen.queryByText so
failures throw with DOM snapshot; locate the test that calls setup() in
VerifyEmailPage.spec.tsx and update the expectation referencing the "Redirecting
to email verification..." string to use getByText(...).toBeInTheDocument() (test
helper: setup).

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

apps/deploy-web/src/services/session/session.service.spec.ts (1)

168-169: Strengthen signup-path assertions to avoid false positives.

These checks are currently too loose for a critical auth flow: the duplicate-user case only asserts call counts, and the token URL assertion accepts any host as long as "/oauth/token" is present. Please assert endpoint + payload explicitly in both scenarios.

Proposed test hardening

-      const { service, externalHttpClient, consoleApiHttpClient } = setup();
+      const { service, externalHttpClient, consoleApiHttpClient, config } = setup();

@@
-      expect(consoleApiHttpClient.post).toHaveBeenCalledTimes(1);
-      expect(externalHttpClient.post).toHaveBeenCalledTimes(1);
+      expect(consoleApiHttpClient.post).toHaveBeenNthCalledWith(
+        1,
+        "/v1/auth/signup",
+        { email: "user@example.com", password: "Password123!" },
+        expect.objectContaining({ validateStatus: expect.any(Function) })
+      );
+      expect(externalHttpClient.post).toHaveBeenNthCalledWith(
+        1,
+        `${new URL(config.ISSUER_BASE_URL).origin}/oauth/token`,
+        expect.objectContaining({
+          username: "user@example.com",
+          password: "Password123!"
+        }),
+        expect.objectContaining({ validateStatus: expect.any(Function) })
+      );

@@
-      expect(externalHttpClient.post).toHaveBeenNthCalledWith(
-        1,
-        expect.stringContaining("/oauth/token"),
+      expect(externalHttpClient.post).toHaveBeenNthCalledWith(
+        1,
+        `${new URL(config.ISSUER_BASE_URL).origin}/oauth/token`,
         expect.objectContaining({
           username: email,
           password
         }),
         expect.objectContaining({ validateStatus: expect.any(Function) })
       );

As per coding guidelines: "Verify meaningful assertions, not just snapshot coverage."

Also applies to: 235-237

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/deploy-web/src/services/session/session.service.spec.ts` around lines
168 - 169, The test currently only checks call counts for
consoleApiHttpClient.post and externalHttpClient.post and loosely checks the
token URL; strengthen the assertions by verifying the exact endpoint and request
payloads using toHaveBeenCalledWith (e.g., assert consoleApiHttpClient.post was
called with the specific signup/duplicate-user endpoint and body, and assert
externalHttpClient.post was called with the full token URL including host and
the exact token request payload/headers). Update both the duplicate-user
assertions around consoleApiHttpClient.post and the token assertions (lines
referenced near 168 and also 235-237) to explicitly check method arguments
rather than just presence of "/oauth/token" or call counts.

apps/deploy-web/src/components/onboarding/steps/EmailVerificationStep/EmailVerificationStep.tsx (1)

44-57: Reset on line 46 may clear user input prematurely.

codeInputRef.current?.reset() is called at the start of handleResendCode, before sendCode() is awaited. If the API call fails, the user loses their partially-typed code. Consider moving the reset to the success path only.

♻️ Proposed fix

   const handleResendCode = useCallback(async () => {
     setIsResending(true);
-    codeInputRef.current?.reset();

     try {
       await sendCode();
       setCooldownSeconds(COOLDOWN_DURATION);
+      codeInputRef.current?.reset();
       notificator.success("Verification code sent. Please check your email for the 6-digit code.");
     } catch {
       notificator.error("Failed to send verification code. Please try again later");
     } finally {
       setIsResending(false);
     }
   }, [sendCode, notificator]);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/deploy-web/src/components/onboarding/steps/EmailVerificationStep/EmailVerificationStep.tsx`
around lines 44 - 57, In handleResendCode, avoid clearing the user's
partially-typed input up-front: move the call to codeInputRef.current?.reset()
out of the start of the function and into the success branch after await
sendCode() succeeds; keep setIsResending(true) at the top and the final
setIsResending(false) in finally, and still call
setCooldownSeconds(COOLDOWN_DURATION) and notificator.success on success, while
notificator.error remains in the catch branch so the input is only reset when
sendCode() succeeds.

apps/api/src/auth/services/email-verification-code/email-verification-code.service.ts (1)

77-84: Local DB updated before Auth0 call—intentional but creates inconsistency window.

If markEmailVerified fails (line 80), the local DB already has emailVerified: true but Auth0 does not. The test at line 165 confirms this is intentional. However, this means a user could be locally verified but Auth0-unverified, which may cause issues if downstream code relies on Auth0's verification status.

Consider adding a reconciliation mechanism or retry queue for failed Auth0 updates if this mismatch causes problems in production.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/api/src/auth/services/email-verification-code/email-verification-code.service.ts`
around lines 77 - 84, The code updates the local flag via
userRepository.updateById before calling auth0Service.markEmailVerified,
creating a potential inconsistency if markEmailVerified fails; modify
email-verification-code.service to handle failures by either (a) rolling back
the local change when markEmailVerified throws (call
userRepository.updateById(userInternalId, { emailVerified: false }) in the
catch) or (b) enqueueing a retry job (push a job to your existing
retry/reconciliation queue with userInternalId and auth0UserId) and keep the
local change, and ensure logger.error still records the failure; pick one
approach and implement it around the auth0Service.markEmailVerified call and its
catch block so the system either reverts local state or reliably retries the
Auth0 update.